A Fast Token-Chasing Mutual Exclusion Algorithm in Arbitrary Network Topologies

Since this problem was first studied by Lann [8] and Lamport [7], it has been extensively investigated for about 20 years. Many algorithms have been proposed to reduce the number of messages, to minimize the access time to the critical region (CR), or to enhance reliability (e.g., [5, 12, 16, 22, 26, 27]). In general, mutual exclusion algorithms are divided into two classes: the permission-based or assertion-based class, and the token-based class. The permission-based algorithms (e.g. [1, 3, 7, 11, 22, 26]) ensure the safety property by obtaining a sufficient number of permissions, and ensure the liveness property by a timestamp method [7] or by managing a distributed acyclic directed graph. The algorithm presented in [26] reduces the number of messages by maintaining a dynamic information structure which is a further improvement on Ricart’s algorithm [22]. On the other hand, the token-based algorithms [1, 2, 5, 12, 14, 17, 18, 21, 25, 27] ensure safety using a unique token, and ensure liveness with a logical ring or a timestamp. In this class, the proposal in [27] reduces the number of messages per CR access required in [22] from 2(N 2 1) to N by using the token (N is the number of processing nodes in the network). Furthermore, the algorithms in [12, 25] reduce the average number of messages per invocation of the CR using the dynamic state information. In all existing distributed mutual exclusion algorithms, designs are aimed at minimizing the number of messages per invocation of the CR. Evaluating mutual execution algorithms by the number of messages per invocation of the CR actually assumes a target network as a type of completely connected underlying communication networks, which ignores the effect of specific communication network topologies. In practice, network topologies have significant impact on the design and performance of mutual execution algorithms. In order to be widely used in system JOURNAL OF PARALLEL AND DISTRIBUTED COMPUTING 35, 156–172 (1996) ARTICLE NO. 0078